Digital data processing systems, hereinafter referred to as "Host Processors", have historically required operator control for the day to day operations of the host processor. Prior art operator/Host Processor interfaces have included an Operation Console directly coupled to the Host Processor. A typical Operation Console included a keyboard for entry of control commands, a plurality of selector switches, one or more banks of indicator lamps, and a CRT display for providing system status information to the operator.
In particular, the Operation Console is the means through which an operator can enter commands to the Host Processor's operating system, and monitor messages coming from the operating system and from other lower level Host Processor control software, thereby controlling the Host Processor. Specifically, the operator can gather information about a host and undertake a number of tasks, some of which are listed in Table 1.
______________________________________ 1. Boot/Start 2. Configure 3. Restart 4. Job Scheduling 5. Job Salvaging 6. Resource Management Disk Drives Tape Drives Memory Instruction Processors 7. User Management 8. File Management 9. React to Exception Conditions and Alarms ______________________________________
Along with the increase in processing capacity of Host Processors has come the increase in operating complexity. With the increase in operational complexity has come the increasing cost of operation. Recognizing the problem of increased cost of operation of Host Processors, those in the industry have set forth various strategies to attack this problem. Three of the various strategies include: 1) easy to use operator interfaces 2) operation automation; and 3) operation centralization.
One implementation of the easy to use operator interface strategy is the commercially available SHIELD Friendly Console for 2200 Series Host Processors sold by the assignee of the present invention. The SHIELD Friendly Console can be used in place of the traditional Operation Console described earlier. The SHIELD Friendly Console consists of software running on a personal computer which provides enhanced display of output messages, a menu driven interface for the generation of input commands to the Host Processor, and context sensitive help. The combination of capabilities provided by the SHIELD Friendly Console helps to make the operation of a complex Host Processor less than an ordeal.
A solution to automate the operation of Host Processors is currently marketed by the assignee of the present invention. Operation automation of 2200 Series Host Processors can be obtained by using the Unisys Smart Console. When combined with the SHIELD Friendly Console, the Smart Console replaces the traditional Operation Console described earlier. The Smart Console consists of software running on a personal computer which is capable of automatically generating commands to the Host Processor and responding to requests for operator input from the Host Processor.
A limited capability for operation centralization has been developed and sold by the assignee of the present invention. This capability consists of hardware and software added to the aforementioned SHIELD Friendly/Smart Console combination which: 1) provides a communications network interface for the Console, and 2) provides a message passing service between software on the Console and software on another computer (e.g. a Workstation) which is coupled to the same communication network to which the Console is coupled.
Centralized operation can be accomplished by coupling a plurality of Operation Consoles to a common communication network and developing a program for the Workstation to establish and maintain a software coupling with a plurality of Consoles. Once the Workstation program has established software connections with the Consoles, another program would provide an operator interface for sending input commands to the respective Consoles and ultimately the respective Host Processors, and receiving messages from the respective Consoles.
While this method of centralized operation brought Console operation of a plurality of Host Processors to a single location, it came at the expense of losing the easy to use operator interface available in the SHIELD Friendly Console. Without reducing the operational complexity of Host Processors through an easy to use interface, the potential number of Host Processors which can be effectively operated at a central location is limited.
In addition to loss of the easy to use interface, the prior art method for centrally operating Host Processors did not provide all functionality available on the Console at the Workstation. This is owed to the fact that the prior art method was based on a message passing scheme. In order to make all Console operational capabilities available at the Workstation, each Console application program would be required to be programmed to handle the message passing interface.
Coupled with the previous two limitations, is the loss of the Console alarm capability in the prior art centralized operations approach. Upon detection of an alarm condition, the prior art Console would notify the local operator through visual cues on the Console Video Display Terminal and audio cues output through a speaker on the Console. With the prior art centralized operations implementation, these visual and audio cues were not sent across the communications network to a Workstation coupled through a network to the Console. Thus an operator at the Workstation had no way of knowing when an alarm condition existed on a Console.
Related to the concept of centralized Host Processor operation is the notion of remote Host Processor operation. Remote operation can be thought of as operation of a Host Processor from a location removed from the physical location of the Host Processor. The extent to which the operational capability is removed from the physical location of the Host Processor goes to the degree to which operations may be classified as remote.
The prior art Console provided the capability to couple the Console to a modem and telephone line, thereby enabling an operator to dial into and communicate with the Console. Once dialed in, the operator could enter input to the Console and have Console output displayed on a dumb terminal. While the prior art console did provide the capability for remote operation, it did not permit more than one terminal at a time to interact with the Console, nor could more than one Console interact with any one terminal.
In using the modem connection as a means to remotely operate a Host Processor, the Console alarm capability (as described above) consisted of sending a character sequence to the coupled dumb terminal. The character sequence caused the terminal to emit an audible cue to the operator. One disadvantage inherent in this scheme is that if a plurality of dumb terminals, all of which are coupled to Consoles, were gathered in a single location, it would be difficult to discern the audio alarms from one terminal from the audio alarms of another terminal.
As described above, the prior art approach to remote and centralized Host Processor operation lacked the full complement of Console functionality and an adequate alarm capability. Neither the centralized nor the remote approach to Host Processor operations found in the prior art provided a consistent and complete user interface as compared with that available at the local Console. Both the visual video display characteristics and the keyboard manipulation necessary for Host Processor operation input at the remote location differed from that found at the local Console. Furthermore, the capability to operate a Host Processor from a plurality of remote locations did not exist.